home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / newsgroups / misc.19941031-19941221 / 000195_news@columbia.edu_Sun Nov 20 04:58:34 1994.msg < prev    next >
Internet Message Format  |  2020-01-01  |  2KB
  1. Received: from apakabar.cc.columbia.edu by watsun.cc.columbia.edu with SMTP id AA07390
  2.   (5.65c+CU/IDA-1.4.4/HLK for <kermit.misc@watsun.cc.columbia.edu>); Sun, 20 Nov 1994 13:25:06 -0500
  3. Received: by apakabar.cc.columbia.edu id AA19892
  4.   (5.65c+CU/IDA-1.4.4/HLK for kermit.misc@watsun); Sun, 20 Nov 1994 13:25:04 -0500
  5. Path: news.columbia.edu!sol.ctr.columbia.edu!news.kei.com!newshost.marcam.com!usc!cs.utexas.edu!news.cs.utah.edu!cc.usu.edu!jrd
  6. From: jrd@cc.usu.edu (Joe Doupnik)
  7. Newsgroups: comp.protocols.kermit.misc,alt.winsock
  8. Subject: Re: winsock/pkt dvr hack possible?
  9. Message-Id: <1994Nov20.105834.33349@cc.usu.edu>
  10. Date: 20 Nov 94 10:58:34 MDT
  11. References: <3a67j8$j39@Mercury.mcs.com> <Pine.SUN.3.91.941118031532.9000A-100000@soleil> <3aiudg$pil@apakabar.cc.columbia.edu> <3anvci$dut@relay.tor.hookup.net>
  12. Organization: Utah State University
  13. Lines: 26
  14. Xref: news.columbia.edu comp.protocols.kermit.misc:1140 alt.winsock:22429
  15. Apparently-To: kermit.misc@watsun.cc.columbia.edu
  16.  
  17. In article <3anvci$dut@relay.tor.hookup.net>, bangus@hookup.net (Brian F. Angus) writes:
  18. > 
  19. > 
  20. > In article <3aiudg$pil@apakabar.cc.columbia.edu>, jaltman@watsun.cc.columbia.edu 
  21. > says...
  22. > 
  23. >>A packet driver on top of winsock makes no sense since winsock is not 
  24. >>protocol independent.  The best you could possibly hope for would be a 
  25. >>Telnet redirector for Windows DOS Sessions which communicates through 
  26. >>WinSock.
  27. > 
  28. > Actually, it could probably be done by filtering out the non TCP/IP
  29. > functionality, but it would be a very complicated bit of engineering.
  30. > You would likely have to write some nasty DOS interrupt redirection
  31. > code which would allow the DOS program to communicate directly to a native Windows 
  32. > WINSOCK application via the packet driver interrupt.  The WINSOCK application 
  33. > would act as a type of pass-through tunnel for the DOS application.  This may 
  34. > require the use of a custom VXD, I'm not sure.  I briefly looked into this but I 
  35. > have decided that my skill sets are not quite at a level required for this task.
  36. -------
  37.     Jeff is correct. The top of a sockets API is a TCP stream channel of
  38. bytes, not packets. "It could be done..." means creating a second TCP/IP
  39. stack feeding from the streams channel and packaging it into TCP/IP over
  40. Ethernet frames to be passed to the application. Not very desirable, nor 
  41. realistic.
  42.     Joe D.